Summary

Spike: remove the VM's DynamicScope concept entirely, replacing it with a minimal
render scope tracker that carries Ember's two ambient values (outletState and the
classic-component view chain).

Stacked on #21485 (its commit is included here): that PR removes the template-facing
dynamic vars (-with-dynamic-vars / -get-dynamic-var); this one removes the machinery
underneath. Related to (but not dependent on) the closed #21450: the tracker here is the
internal core of what that PR's glimmer side did — the render-tree-positional
provide/lookup mechanism — without any public createContext API. If a Context feature
lands later, it can grow out of this same mechanism instead of a parallel one.

The replacement mechanism

RenderScopeStackImpl (@glimmer/runtime/lib/render-scope.ts): a parent-linked tree
with one node per component that has the (renamed) renderScope capability. A component
provides values on its own node during create; descendants read the nearest
provided value by walking the parent chain.

Two properties make this a faithful replacement for dynamic scope:

1. Provide-on-own-node means isolation is free. Dynamic scope had to push a fresh
   child scope around every component that might contain a mutating descendant, so
   custom-manager (Glimmer) components all carried dynamicScope: true purely to stop
   set from leaking to siblings. With provides landing on the provider's own node,
   nothing can leak, and custom-manager components flip to renderScope: false — fewer
   scope frames than before, not more.
2. Update re-entry is handled by paired updating opcodes. The old ops 59/60 became
   VM_PUSH_RENDER_SCOPE_OP / VM_POP_RENDER_SCOPE_OP; on the append pass they push/pop
   nodes and install EnterRenderScopeOpcode/ExitRenderScopeOpcode in the updating
   opcode list. The updating VM therefore re-establishes the correct node as it descends,
   so content re-rendered mid-update (a TryOpcode re-rendering after a route change,
   an {{#if}} flipping around an {{outlet}}) sees the same ambient state it would on
   initial render. This is the job closure capture of dynamicScope used to do.

Removed

• DynamicScope interface (get/set/child), DynamicScopeImpl
• The VM's dynamic scope stack, pushDynamicScope/popDynamicScope/dynamicScope(),
  and the dynamicScope field captured in every block closure (ClosureState/VMState)
• The dynamicScope parameter threaded through renderMain/renderComponent,
  WithCreateInstance#create, WithUpdateHook#update, and the internal helper signature
• Ember's DynamicScope class in renderer.ts (and its outletState-only assertions)
• The fromDynamicScope test-infra feature in emberish-curly

Renamed / migrated

• Capability dynamicScope → renderScope (same bit); ops 59/60 renamed as above
• Ember's ambient values live in @ember/-internals/glimmer/lib/utils/render-scope.ts
  as private symbols: the outlet component manager provides OUTLET_STATE; the
  {{outlet}} helper reads the nearest one (internal helpers now receive the current
  RenderScopeNode instead of a DynamicScope); curly/root managers provide/read VIEW
  for the classic parentView chain

Testing

• pnpm type-check:internals — clean (the two @glimmer/component errors in owner
  type-tests are pre-existing on main)
• pnpm lint:eslint — clean
• vite build + full testem browser suite — 9382 tests, 9365 pass, 17 skip, 0 fail
  (identical tally to main + [SPIKE] Remove -with-dynamic-vars / -get-dynamic-var support #21485, so outlet nesting, engines, and the classic
  parentView chain are all exercised and passing)
• grep -ri dynamicscope packages/ — zero remaining references

🤖 Generated with Claude Code